Is Devops Engineer a Title?

Yes, I know. This horse is dead. We have all (mostly) accepted the fact that "DevOps Engineer" as a title is here to stay. Companies advertise it in job descriptions. Engineers, including myself, have it on their resume. So just move on right? Sure, but there is something to be said for avoiding this title and the positions that define it.

There are large tech companies that practice DevOps without a single DevOps Engineer. I think they have it right.

Seriously, What's the Big Deal?

It's obvious I dislike the title "DevOps Engineer". I'm not alone, many posts have been written about it simply being a "re-branded SysAdmin" but that's not the reason I dislike it. Most will think it's the typical objection: "DevOps iS a PrOCeSs!" But that's not it either. Those reasons are a bit superficial and easy to remedy, I think the issue is a bit deeper.

My reason is simple: it's an unnecessary title that attempts to categorize an engineer ambiguously. Forget what SysAdmins used to do and disregard the DevOps philosophy for just a moment. When an ambiguous title, such as DevOps *, is applied to a person or team, misconceptions about their purpose follow.

These misconceptions tend to fly in the face of the DevOps philosophy by creating a silo that DevOps was meant to eliminate. If you've worked in an organization that implemented a "DevOps team" you've probably witnessed this confusion. Often it sounds like, "..that's DevOps' job" or "..that's not what DevOps does". Not only is this frustrating as an engineer, but also signals that there is a DevOps Anti-pattern in place.

What Is My Title Then?

I have two simple suggestions for this. If your time is spent writing software - scripts, utilities or tooling - to support the process used to implement DevOps, you are a Software Engineer (SWE). You may not be contributing directly to the application itself, but you are still an SWE. We have many facets of SWE - front-end, back-end, test - this is just another one. Bite the bullet and own the fact that you are building software in one of its many forms.

If that's not your main purpose and you focus on building, deploying and maintaining the underlying infrastructure for applications to run, you are Operations. This title is completely apt but seems to be avoided due to a perceived lack of sex appeal. Maybe Ops isn't a hot title these days but it is critical and avoiding the name masks the purpose of the team.

There are, of course, times when the two suggestions overlap. In that case, feel free to be inventive and give your Ops team a sexy new name. Just make sure it isn't misleading and that your adjacent teams know exactly what you provide.

Is this Really Important?

I've worked with many DevOps Engineers over the last few years. Some absolutely cannot write code, some loathe the idea of doing typical ops tasks. They were hired as "DevOps Engineers" but the ambiguous title led to unrealistic expectations on behalf of the company and the engineer. So yes, it matters. It matters to both the company and the individual engineer.

Companies should be clear about what they need in an engineer. Simply stating that an engineer will be "DevOps" with a laundry list of tools and cloud provider experience says very little about the actual expectations.

As a potential employee, you owe it to yourself to ask about the exact nature of the position during the interview process. As an employer be clear about the engineering skills and type of work you are hiring for. The best solution is to simplify our titles and own what we do in our profession, regardless of trends.